In the related art, there is a technique in which a plurality of different databases (hereinafter referred to as DBs) are integrated so as to be managed as one database. For example, a technique exists in which a configuration management database (CMDB) for integrating pieces of configuration information of a system stored in a plurality of DBs, DB-1 to DB-3, and managing the configuration of the entire system is constructed.
A CMDB has a function (reconciliation function) of, when integrating pieces of information retained in databases, determining the identicalness of pieces of configuration information and merging pieces of configuration information which are determined to be the same. As for determination of the identicalness of data, data to serve as a key for determining the identicalness of data is preset from among pieces of common information retained in target databases to be integrated, and it is determined whether or not the data set as the key (or a hash value generated on the basis of the data) matches data in each database.
Now, an integration process performed in a CMDB will be described by using FIG. 21. FIG. 21 illustrates an example of constructing a CMDB by integrating three DBs which are DB-1, DB-2, and DB-3. The DB-1 stores information of IP=“192.168.0.1” and NAME=“name_XXX” of a device “NODE_A”. The DB-2 stores information of ID=“192.168.0.1” and HDD=“Disk_abc” of a device “Server 1”. The DB-3 stores information of IP_ADDR=“192.168.0.1” and CPU_INFO=“CPU A” of a device “HOST_X”.
Although the DB-1, the DB-2, and the DB-3 each perform storing in their own data formats, for example, the data of “192.168.0.1” is data commonly stored in the DB-1, the DB-2, and the DB-3. In this case, it may be determined that “NODE_A”, “Server—1”, and “HOST_X” represent the same device. Hence, pieces of data stored in the DB-1, the DB-2, and the DB-3 are converted from their own data formats of the DB-1, the DB-2, and the DB-3 into a common data format and are integrated into the CMDB by using an ipAddress attribute as a key for integration. In this way, information of Name=“name_XXX”, CPU=“CPU_A”, and Disk=“Disk_abc” of the device with ipAddress=“192.168.0.1” (“SERVER_XXX” illustrated in FIG. 21) may be obtained from the CMDB.
Problems
DBs to be integrated into a CMDB each update configuration information stored therein and supply data of information changed due to updating (changed data) to the CMDB at their respective transmission intervals, thereby causing a significant time difference between old and new versions of data to be integrated in the CMDB. For example, the DB-1 in FIG. 21 transmits changed data once a minute, whereas, in some cases, the DB-2 and the DB-3 transmit changed data once a day.
When a process of integrating data is performed in the CMDB in this situation, configuration information in which a change has been reflected has already been obtained from a DB, whereas configuration information in which a change has been reflected has not yet been obtained from another DB, thereby resulting in integrated data having a mixture of old data and new data in some cases. When system settings are set by using such integrated data exhibiting inconsistencies, an application executed as a component of a system may malfunction.